另类分布式存储：ZFS+SAS交换已经有人在搞？
昨天下午，有家国内厂商的分布式存储发布会，由于之前了解到他们的产品有些“与众不同”，因此出于对技术的兴趣而去学习了解一下。本文就来写写个人的心得，只谈产品技术，不会特别去介绍这家公司，也不代表我所在公司的立场。
对于SurFS宣传的“极高性能、极低成本、高可靠、高可用、扩展性好”，是否真的如此？我希望这篇解析能够给国内存储技术同行和用户带来参考一定的价值。
首先，借用VMware VSAN的架构图来看下现在主流的分布式存储/ServerSAN。
上面是一个3节点VSAN集群示意图，每台服务器的本地存储——1个SSD缓存+若干硬盘聚合成一个整体的存储池。这是典型的Shared-Nothing（相对于传统共享存储来说）、Scale-out横向扩展的架构，集群间互连通信通常使用10Gb或者更高速率的以太网。
以上就是目前流行的分布式软件定义存储，包括Nutanix、Ceph等硬件形态上都是大同小异。如果在存储节点上同时运行用户的虚拟机，就是超融合了。
SurFS硬件：SAS交换后端确实成本低
这次发布的SurFS也叫“分布式文件系统”，而上面的架构图与前面的分布式块存储有明显的差别。
其实在发布会之前，我在网上已经听说书生云使用了后端共享的SAS交换架构。所有磁盘驱动器/SSD位于和服务器节点分开的JBOD机箱中，经过SAS交换机与存储控制节点连接，这里“CPU总线”的含义——计算节点是运行在存储控制节点这台服务器上的虚拟机。
左边还说它“第一个用SAS做存储网络”？我一下就想起了刀片机箱里的SAS交换机。24Gb/48Gb带宽就是指6Gb/s SASx4 lane和12Gb/s SAS x4 lane连接，如果要达到12Gb对SAS交换机、JBOD上的连接模块（也是SAS Switch）和服务器上HBA卡都有要求。这样的带宽在目前主流应用中，对单一物理服务器、JBOD来说基本满足需求。
控制节点与存储介质分离，相当于可以单独扩充计算节点和存储单元，Scale-out与Scale-up的结合。数据路径短，就是说每台服务器操作的硬盘/SSD都接近本地盘的延时，不需要像VSAN等那样通过以太网跨服务器节点读/写数据以保证冗余高可用。
全局存储池——所有驱动器对每台服务器都可见，这里的纠删码不需要跨节点I/O，所以相当于RAID 5/6/三重校验？如果一个存储控制节点故障，硬盘/SSD都可以被别的节点接管。至于Re-blance，还有最后一条所说的各种优点，不能光看硬件，还要看存储软件设计。
如上图，富士通的高端存储曾经采用过后端SAS全互连的架构。不过这里是点对点连接而没有用集中的SAS交换机，每个CM（控制器）上的4个IOC（SAS控制器）会连接到后端驱动器机箱的每一个BRT（Back-End Router，其核心也是SAS Switch）。
DX8700 S2没有用SAS交换机的理由其实也简单——64个上/下行SAS x4无阻塞连接，是现有16口SAS交换机吃不消的。所以性能哪个更高一眼就可以看出来——当然价格也不在一个Level。然而，估计是由于这个背板连接太复杂，到富士通新一代产品也改回像EMC VMAX那样的后端架构了。
VMAX高端阵列的驱动器机箱，只在同一Engine的两个Director（双控）之间共享。这类产品，包括3PAR在内都是靠控制器间的高速RapidIO/InfiniBand/PCIe交换架构，来保证跨节点的磁盘I/O效率，XtremIO全闪存阵列也是如此。
那么SurFS比它们成本低，是毋庸置疑的。
SurFS软件：目前ZFS，未来分布式全局缓存
SurFS目前的底层基于开源文件系统ZFS，考虑的就是其成熟可靠。书生云也比较坦诚地写了ZFS的问题：
1、Failover导入时间。ZFS设计之初是个单机文件系统，其高可用是通过第三方HA Cluster插件来实现的，因此zpool的故障切换没有传统双控阵列那么快。
2、存储控制节点故障会丢失缓存数据（可靠性达不到企业存储标准？）。熟悉ZFS的朋友估计看懂了，SurFS为了性能没有强制ZIL日志数据同步写入磁盘，而是利用服务器内存做写缓存，这部分数据没有保护。
针对这一点，为什么不在JBOD中放SSD存ZIL？答案也很简单，性能不够理想。对于高速SSD来说，SAS接口（特别是6Gb/s SAS）还不够快。
保障不了全部数据的可靠性显然不是长远发展之计，因此SurFS未来计划“废弃ZFS直接管理存储介质”，除了提高Fail-over速度之外，快速重建故障盘和资源池化应该就是指宽条带化RAID，这个在传统存储上早已实现，除了HP EVA，还有如今仍流行的戴尔SC（Compellent）、HP 3PAR和NetApp/DellMD3的DDP等。
全局缓存池，就是为了解决单台服务器故障时丢数据的问题，这一点所有Scale-out设计的高端阵列、分布式存储/ServerSAN都要面对。尽管叫法不同（比如：分布式缓存一致性等），但都是要跨节点维护数据副本，VSAN的写缓存是用SSD，如果SurFS还是用内存的话，多个存储控制节点同时掉电不知有没考虑过？
本质上看，SurFS未来才会有一个真正的分布式存储软件，而它的后端磁盘又是全局共享的，软件基础功能应该与富士通DX 8700 S2有些类似，要想做得比较完善估计比现在这个要难了？
国外同类架构、SAS扩展限制
这张图我就是想让大家看看双SAS交换机的冗余后端网络。传统的ZFS双控存储是用2台服务器同时连一个JBOD，比如DellR730+MD1xx0/MD3060的组合。
其实在技术上ZFS做成SurFS这样的配置并没有限制，从网站上我看到了相关的证据。包括以下文字和一张架构图：
“Soif you were adding SAS switches or even Ethernet switches (AoE like Coraid)you could en up with real scale-out AND scale-up intopetabytes within no-time… Right now, you are looking at a 4controller 500TB (4x120x900GB 10k) scale-out NAS you have build on yourown. I did this on DELL hardware because that is something I know best…”
这个图中有4台Dell服务器、16个MD1220/1420 JBOD分为4组级联，中间是2个16端口SAS交换机。由于每台服务器到每个交换机都采用了双SAS线缆，如果改成单链路且保持冗余的话，服务器+连接到交换机的JBOD总数最多为16台——这应该也是SurFS当前的扩展限制。
单从这一点来看，当前SAS交换式后端的分布式存储，其扩展性与以太网互连的分布式存储还是无法相比的。除非更多端口的SAS交换机出现，或者有别的扩展技术。
未完待续…
下篇要点
JBOD节点冗余实现、以太网扩展选项
SAS交换机的限制、未来展望
开源与OpenStack整合
通用模式（SAN）与聚合模式（超融合）
性能PK：应该怎么看？
注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎批评指正。进一步交流技术，可以加我的QQ/微信：490834312。
请在本公众号发布2天后，才能转载本文（微博/微信转发分享不限）。尊重知识，请必须全文转载，并包括本行及如下二维码。
感谢您的阅读和支持！《企业存储技术》微信公众号：huangliang_storage
长按二维码可直接识别关注